Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Governance

Governance is who decides, on what basis, and what happens when someone decides otherwise. It is the layer at which most national digital health programmes actually fail — not for want of architecture, but because nothing prevented the next project from ignoring it.

The single question that tests whether digital health governance is real: can the architecture function stop a procurement? If not, it is advisory, and every vendor knows it.

The bodies​

BodyDecidesMeets
Digital health steering / governance committeeStrategy, investment priorities, cross-agency issuesQuarterly
Architecture review boardWhether a proposed system conforms; exceptions and their expiryMonthly, or on demand
Data governance councilData ownership, access, sharing, quality accountabilityMonthly
Standards and terminology committeeWhich standards and versions; value set releasesPer release cycle
Clinical safety groupClinical risk of digital changes, including decision support and terminologyPer significant change
Security and privacy functionControls, incidents, risk acceptanceContinuous

Small countries do not need six bodies. They need these six functions, which may be three people wearing several hats. What they cannot do without is a written record of who holds each function.

Architecture governance​

What the review board reviews: any new system, any significant change to an existing one, any integration, and every procurement above a threshold.

Against what: the published architecture principles, the standards register, and the registries. A concrete, testable checklist rather than a discussion — see checklists.

Outcomes: approve, approve with conditions, reject, or grant a time-limited exception. Exceptions are essential — a board that only says no gets bypassed — but every exception needs an expiry date, a named owner and a remediation plan. Exceptions without expiry are how architecture erodes.

Architecture principles worth publishing, as examples:

  1. Systems use the national identifiers from the registries
  2. Data is exchanged using published standards and profiles, not bespoke formats
  3. One system is the source of truth per data domain
  4. Systems must function in degraded mode when central services are unavailable
  5. Data is extractable in a standard format; no system holds data hostage
  6. Personal data stays within the jurisdictions the law permits
  7. Decisions are recorded as ADRs

Each principle should be testable at review. "Systems should be interoperable" is not a principle; it is a wish.

Data governance​

Detailed treatment in data governance. The architectural essentials:

  • Ownership — a named owner per data domain, accountable for quality and access decisions
  • Stewardship — who operates the registries and value sets day to day
  • Access decisions — who may authorise a new consumer, a bulk export, a research use
  • Quality accountability — metrics published by facility and district, with someone answerable
  • Retention and disposal — periods defined and enforced
  • Secondary use — a documented process for research and commercial requests, including what is refused

Standards and terminology governance​

The function that decays fastest without ownership.

  • Standards register — which standards, which versions, which profiles are current; what is deprecated and when it will be withdrawn
  • Upgrade policy — how and when the ecosystem moves from one FHIR version or ICD revision to the next, and who bears the cost
  • Implementation guide ownership — who may change the national IG, on what cycle, with what notice
  • Value set release process — request, review, publish, notify. See terminology services
  • Conformance testing and certification — what a system must demonstrate before it joins the exchange, and re-testing after upgrades

Treat terminology releases as changes, not as data. A value set update can alter what a decision support rule fires on. They belong in the high-risk change tier — see DevSecOps — and often warrant clinical safety review.

Procurement​

Where architecture is enforced or abandoned. Requirements that belong in every health system tender:

  • Support for the national identifiers, storing local and shared identifiers
  • Conformance to the named implementation guide, demonstrated by test, not asserted
  • Published, documented APIs, with no additional licence fee for integration
  • Data extractable in a standard format on demand and at exit, with the cost stated in the contract
  • Terminology configurable, not hard-coded
  • Audit logging to the required standard
  • Security requirements, including vulnerability disclosure and patching commitments
  • Offline or degraded-mode behaviour, where relevant
  • Source code escrow or open source, where appropriate
  • Total cost over ten years, including hosting, support and upgrades

The exit clause is the one most often omitted and the one that most determines long-term cost. A system whose data cannot be extracted affordably is a permanent commitment regardless of how the contract is written.

Avoid specifying products. Specify capabilities, standards and conformance. A tender that names a product has made an architecture decision through a procurement document, without review.

Open source governance​

Many health platforms are open source, which changes the questions rather than removing them:

  • Who maintains the deployment? Open source is not free of cost; it relocates the cost to your team or an integrator.
  • What is the upstream relationship? Are local changes contributed back, or maintained as a fork? Forks diverge, and diverged forks stop receiving security updates — this is the single most common failure mode in government open-source deployments.
  • Which version, and what is the upgrade path?
  • Who has commit rights to national extensions and configurations?
  • What is the community's health? See platform directory for the assessment criteria.
  • License compatibility with how the system will be used and distributed.

A policy worth adopting: local modifications are contributed upstream by default, and a fork requires an explicit decision recorded as an ADR.

AI governance​

New enough that most ministries have no process. Minimum viable structure, drawn from AI architecture and WHO guidance:

  • An inventory of AI systems in use, including those embedded in procured products — this alone is often revealing
  • A named clinical owner per model
  • Documented intended use, and explicit out-of-scope uses
  • Local evaluation before deployment, reported by subgroup
  • Regulatory classification — is it a medical device in this jurisdiction?
  • Monitoring with defined thresholds and an explicit stopping rule
  • Review dates, and a body that conducts the reviews
  • An incident process for suspected model harm

Note that "AI embedded in a procured product" is where most AI enters a health system, and where governance is most often absent. Procurement questions about AI components belong in the checklist above.

Making governance stick​

Observed determinants of whether it works:

  1. Authority over money. Governance that cannot condition funding or procurement is decorative.
  2. A small number of enforced rules beats a comprehensive framework nobody reads.
  3. Fast decisions. A review board with a six-week queue gets bypassed for reasons everyone considers reasonable.
  4. Published decisions. Transparency makes precedent, and precedent reduces the volume of decisions.
  5. A named permanent function, not a project role. Programmes end; governance must not.
  6. Exception paths with expiry. Rigidity produces circumvention.

References​

Last updated on